Will W wrote:
> POV's method is consistent within its intended framework. The behavior is
> that truncation is always to the lower magnitude, which often is what you
> want when working in a cartesian coordinate system (where the negation of
a
> value should be a symmetrical with the first value around the origin).

I don't see why anyone would want mod(-x, m) to be symmetrical with mod(x,
m).

> Another aspect of the problem that is going unrecognized here is that
while
> mathemeticians deal with a true integer number line, there is no way to
> represent that number line in any computer I know of. The best that can be
> done is to set up a large "number circle"-- but there will be some maximum
> number which when incremented will yield a negative number, and some
minimum
> number which when decremented will yield a positive number.

That's not true with floating-point numbers, which is what we're talking
about here. Besides, even if they were integers, the result of mod(-1, 3) is
much more important than the result of mod(-2147483648, 3).

> While it is true that the current method makes conversion of negative hue
> values more difficult, it also makes operations in POV's vector space more
> dwim.

How so?

> I'm sort of confused about negative hue values anyway-- the concept
> strikes me as unnatural.

Of course you wouldn't directly enter a negative hue, but suppose you want
to shift all the hues in some picture down by 10 -- then you get negative
hues pretty quickly. If you prefer, think of shifting an angle by 10
degrees. This is exactly the kind of thing that mod is for, but POV-Ray's
mod is nearly useless in this case.

Anders

Post a reply to this message